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analysis  provided  by  the  management  office,  and  obtain  the  benefits  listed. 
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The  overall  goal  of  the  Ports, 
Protocols,  and  Services  Management 
Process  (PPSMP)  [1]  is  to  improve  both 
the  interoperability  of  joint  applications 
and  the  security  of  the  overall 
Department  of  Defense  (DoD)  informa¬ 
tion  infrastructure.  The  process  supports 
many  people  in  many  roles:  program  man¬ 
agers,  systems  engineers,  software  devel¬ 
opers,  network  operators,  network  securi¬ 
ty  managers,  router  and  firewall  adminis¬ 
trators,  etc. 

The  authors  hope  this  article  reaches 
many  of  those  people,  and  helps  them 
understand  both  the  value  of  participat¬ 
ing  in  the  PPSMP  and  the  services  it  can 
provide. 

For  reader  clarification,  we  begin  this 
article  with  a  discussion  of  the  basic  terms 
and  concepts  of  computer  network  traffic 
on  the  Internet:  protocol,  Internet  proto¬ 
col  (IP),  IP  protocol,  service/application 


protocol/ data  service,  and  port. 

Protocol 

A  protocol  is  simply  an  agreed  upon  way 
to  communicate  or  interact.  This  word 
can  have  multiple  meanings  in  different 
contexts.  The  meaning  and  context  will 
become  apparent  below. 

Internet  Protocol 

The  most  fundamental  protocol  is  the  IP. 
The  international  group  Internet  Engi¬ 
neering  Task  Force  (IETF)  [2]  sets  the 
standards  for  the  IP.  The  IETF’s  many 
standards  documents  -  both  draft  and 
approved  -  called  “Requests  for  Com¬ 
ment  (RFC),”  are  at  <www.ietf.  org>. 

The  core  principal  of  the  IP  is  that  all 
information  travels  between  computers  in 
data  bundles  called  packets  rather  than  in 
a  continuous  stream.  Any  information,  for 
example  a  computer  file,  can  be  divided 


into  packets  by  the  sending  computer  and 
the  packets  reassembled  into  the  complete 
file  by  the  receiving  computer.  The  IP 
defines  several  structures  so  this  can  hap¬ 
pen.  The  two  most  important  are  an 
addressing  scheme  and  a  defined  packet 
structure.  Figure  1  illustrates  the  IP  com¬ 
munications  concept. 

An  IP  address  is  like  a  computer’s  tele¬ 
phone  number.  You  may  have  seen  these 
four  groupings  of  numbers  separated  by 
periods  (or  dots).  Those  are  IP  addresses 
as  defined  under  Version  4  of  the  IP  stan¬ 
dard  currently  in  use  internationally. 

Each  of  the  four  number  groups  can 
be  any  number  from  0  to  255.  Many  coun¬ 
tries,  as  well  as  the  DoD,  are  upgrading  to 
IP  Version  6  (IPv6),  which  uses  a  very  dif¬ 
ferent  address  scheme.  To  save  space,  this 
article  does  not  discuss  IPv6  addressing. 
Many  resources  on  IPv6  are  available  for 
the  readers1. 

Once  two  computers  find  each  other, 
they  need  to  agree  on  how  to  communi¬ 
cate.  The  defined  packet  structure  assists 
in  this  process.  Very  simply,  each  packet 
has  two  major  parts:  the  header,  with 
information  about  the  packet,  and  the 
payload,  with  the  actual  data.  Figure  2 
illustrates  this  concept. 

More  than  100  standard  rule  sets,  each 
with  a  different  purpose,  are  available  for 
the  computer-to-computer  communica¬ 
tion.  Here  are  examples  of  a  few  of  the  IP 
protocols  most  often  seen  on  networks: 

•  Protocol  1:  ICMP  -  Internet  Control 
Message  Protocol.  ICMP  packets 
allow  two  operating  systems  to  trade 
status  messages.  A  ping  is  a  single 
packet  sent  from  one  computer  to 
another  that  means  simply,  “Are  you 
there?”  If  the  receiving  computer  is 
listening  for  the  ping  and  chooses  to 
admit  it  is  available  for  further  contact, 


Figure  1 :  IP  Communication 


Internet  Protocol  (IP)  Communication 

•  Packets,  Not  Continuous 

•  Standard  Worldwide  Addresses 

•  Standard  Packet  Structure 
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Figure  2:  IP  Protocols 


it  replies  with  a  one-packet  ping  reply, 
which  tells  the  first  computer,  “Yes, 
I’m  here  and  listening.” 

Why  is  it  named  ping!  The  name  is 
borrowed  from  the  world  of  sub¬ 
marines  and  sonar.  Think  back  to 
every  submarine  movie  you  have  seen. 
The  sound  sent  out  by  the  sonar  is 
called  a  ping,  because  of  the  way  it 
sounds  on  the  speakers  when  reflected 
back  to  the  submarine  by  the  enemy 
ship  lurking  in  the  distance. 

•  Protocol  6:  TCP  -  Transmission 
Control  Protocol.  TCP  packets  sup¬ 
port  positive  confirmation  that  each 
chunk  of  data  (packet)  arrived  intact 
and  unchanged.  This  confirmation  is 
essential  when  sending  data  that  must 
not  be  lost  or  corrupted,  such  as  a 
database  record. 

•  Protocol  17:  UDP  -  User  Datagram 
Protocol.  UDP  packets  can  carry  any 
content  data,  but  they  do  not  provide 
a  feedback  mechanism  to  confirm 
receipt  of  intact  data.  UDP  is  used  to 
push  large  amounts  of  data  (packets) 
out  from  the  computer,  and  it  is  not 
critical  if  some  of  them  get  lost  or 
broken,  such  as  streaming  audio  or 
streaming  video. 

•  Protocol  50:  ESP  -  Encapsulating 
Security  Payload.  ESP  packets  have 
the  primary  data  encrypted;  only  the 
sender  and  receiver,  who  have  the  right 
encryption  keys,  can  read  die  data. 
This  protection  of  confidentiality  is 
part  of  the  IP  security  set  of  stan¬ 
dards,  and  is  the  basis  for  many  virtual 
private  networks. 

Here  is  jargon  watch  No.  1:  Protocol  is 
the  first  word  in  this  discussion  widi  mul¬ 
tiple  meanings.  The  IP  defines  die  overall 
structure  of  packets  and  IP  addresses.  The 
IP  protocol  defines  the  major  type  and 
function  of  packets.  (Yes,  spelling  out  IP 
protocol  as  Internet  protocol  protocol  does 
sound  redundant,  but  it  is  accurate.  That  is 
why  you  never  see  it  spelled  out.)  The  next 
term  to  be  discussed,  service,  is  also  called 
the  application  protocol.  In  the  context  of 
the  PPSM,  protocol  most  often  refers  to 
the  IP  protocol. 

Service 

Once  two  computers  are  communicating 
with  the  proper  hardware  system  address¬ 
es  (IP  address),  and  computer-to-comput- 
er  packet  type  (IP  protocol),  the  individual 
programs  on  each  computer  still  need  to 
communicate  properly.  The  programs 
must  exchange  data  in  the  right  format 
and  packet  structure  for  die  programs 
themselves  to  understand.  The  rule  for 
the  agreed  format  at  this  level  is  called  var¬ 


iously  the  application  protocol,  data  service,  or 
simply  service.  All  three  terms  refer  to  the 
same  aspect  of  the  packet. 

While  die  IP  has  provisions  for  up  to 
only  256  different  protocols,  it  has  set  no 
limit  on  the  number  of  possible  services. 
Every  application  programmer  could 
devise  unique  services  for  the  programs  to 
use  to  communicate  over  a  network.  In 
die  interests  of  both  interoperability  and 
ease  of  programming,  most  do  not. 
However,  new  programs  introduce  new 
services  every  year.  Some  are  proprietary, 
while  others  become  widely  used  stan¬ 
dards. 

There  are  thousands  of  these  services 
or  application  protocols  because  different 
types  of  programs  need  different  types 
and  orders  and  formatting  for  their  data. 
Programmers  who  hope  to  see  an  appli¬ 
cation  protocol  become  a  standard  may 
publish  the  specification  as  a  RFC  with 


the  IETF,  but  they  are  not  required  to  do 
so.  Figure  3  illustrates  the  use  of  these 
services. 

Examples  of  well-known  and  com¬ 
monly  used  services  include  hypertext 
transfer  protocol  (http),  used  for  sending 
Web  pages;  file  transfer  protocol  (ftp), 
used  for  moving  entire  data  files  between 
computers;  and  telnet,  used  for  remote 
computer  terminal  connections. 

Within  the  packet-structure  logic 
described  so  far,  generally  only  two  proto¬ 
cols  carry  packets  that  contain  a  defined 
service  at  the  next  level:  TCP  and  UDP.  In 
fact,  many  services  can  travel  in  either. 
Program  architects  decide  which  protocol 
to  use  depending  on  whedier  the  priority 
is  higher  speed  or  packet-count  dirough- 
put  (UDP),  or  100  percent  intact  packet 
arrival  (TCP). 

Here  is  jargon  watch  No.  2:  Within  die 
PPSM,  service  refers  to  the  data  service  or 


Figure  3:  Service 

Service  -  How  Programs  Talk 
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•  May  Be  Standard  or  Proprietary 
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application  protocol  as  just  described. 
However,  in  the  world  of  network  engi¬ 
neering,  service  can  refer  to  a  level  or  qual¬ 
ity  of  service  of  the  network  (actual  data 
transport  speed  limit  and  network  avail¬ 
ability).  Service  can  also  refer  to  a  catego¬ 
ry  of  application  running  on  a  computer 
such  as  a  Web  service,  a  tile  service,  a  time 
reference  service,  a  chat  service,  and  so 
forth.  A  computer  running  one  or  more 
services  is  called  a  server  (Web  server,  tile 
server,  time  server,  or  chat  server,  for 
example). 

Port 

The  IP  address  sends  each  packet  to  die 
right  computer.  The  IP  protocol  tells  die 
receiving  computer  the  packet  type.  The 
service  indicated  in  the  packet  tells  die 
receiving  program  the  data  structure. 
However,  each  computer  may  have  many 
different  programs  running  at  the  same 
time.  And  each  program  may  be  having 
conversations  with  more  than  one  other 
computer  at  the  same  time. 

For  instance,  a  file  server  may  be 
receiving  thousands  of  requests  to  send 
out  files  to  individual  remote  computers 
in  the  same  minute.  If  the  server  agrees  to 
support  all  of  those  requests,  it  needs 
some  way  to  sort  the  incoming  traffic  to 
keep  track  of  each  two-way  conversation, 
or  session,  separately. 

The  concept  of  the  port  provides  die 
tool  for  managing  multiple  simultaneous 
sessions.  For  TCP  and  UDP  packets  with 
defined  services,  each  packet  also  specifies 
a  port  number.  The  standard  packet  struc¬ 
ture  reserves  enough  room  for  the  port 
number  so  it  could  be  any  number  from  0 
to  65,535. 

Think  of  each  computer  as  an  office 
Figure  4:  Ports 


building  with  one  street  address  (the  IP 
address),  but  many  mailboxes  for  the  sep¬ 
arate  offices.  Think  of  the  port  number  as 
die  number  on  each  of  those  internal 
mailboxes.  Some  offices  (programs)  by 
agreement  use  a  standard  local  mailbox 
(port)  number.  For  example,  bulk  mail 
delivery  goes  to  port  25,  requests  for  Web 
pages  go  to  port  80,  and  requests  for  ter¬ 
minal  sessions  (telnet)  go  to  port  23. 
Figure  4  illustrates  the  use  of  ports. 

To  help  keep  multiple  conversations 
separate  once  a  contact  is  started  the  host 
may  say,  “Send  everything  else  for  this 
session  to  one  of  my  high  number  boxes. 
This  is  temporary,  just  for  this  exchange.” 
These  are  dynamic  or  transient  (or  ethere¬ 
al)  ports. 

By  convention  and  as  defined  by  both 
the  IETF  and  the  Internet  Assigned 
Numbers  Authority  (IANA)  [3],  port 
numbers  from  0  to  1,023  should  be  used 
only  for  the  standard  services  as  registered 
with  IANA.  Other  services  should  use 
port  numbers  above  1,024.  Developers 
may,  if  diey  wish,  register  with  IANA  any 
proprietary  or  non-standard  service’s  use 
of  particular  ports  above  1,024.  This  does 
not  really  reserve  those  ports  for  only  that 
use,  but  it  does  notify  all  network  users 
and  engineers  of  the  planned  use. 

Here  is  jargon  watch  No.  3:  In  the  con¬ 
text  of  the  PPSM  and  IP  packet  headers, 
port  refers  to  the  number  diat  helps  man¬ 
age  communication  sessions.  This  infor¬ 
mation  is  important  to  network  engineers 
and  administrators  who  manage  routers 
and  firewalls,  as  described  in  die  next  sec¬ 
tion.  However,  those  same  router  and  fire¬ 
wall  administrators  also  use  port  to  refer 
to  the  physical  connection  on  hardware 
where  they  plug  in  a  network  cable. 


Boundary  Filtering  -  Routers  and 
Firewalls 

So,  why  does  the  PPSM  care  about  all  of 
those  standards?  Because  network  admin¬ 
istrators  can  use  them  to  enforce  rules  on 
network  traffic  via  routers  and  firewalls. 
Figure  5  illustrates  the  use  of  firewalls. 
These  rules  can  help  limit  traffic,  block 
problem  traffic,  and  allow  favored  traffic. 
Many  network  management  and  security 
devices  can  use  the  information  in  packet 
headers  to  decide  how  to  handle  the  pack¬ 
ets.  Remember,  each  packet  begins  with  a 
header,  which  is  like  an  envelope,  contain¬ 
ing  the  following  information:  IP  address 
from,  IP  address  to,  IP  protocol  (packet 
type),  service  type  (if  needed),  port  num¬ 
ber  (if  needed). 

Administrators  can  devise  and  apply 
rules  based  on  header  items,  as  follows: 

•  Deny  any  traffic  that  comes  from  a 
particular  IP  address  or  range  of 
addresses. 

•  Deny  any  traffic  that  uses  a  service  for 
a  program  diat  only  insiders  should  be 
using. 

•  Allow  any  traffic  using  the  standard 
port  for  a  standard  service  (application 
protocol). 

•  Deny  any  traffic  using  a  nonstandard 
port  for  a  service  declared. 

Policy  and  Process 

The  purpose  of  the  ports  and  protocols 
policy  is  to  provide  the  DoD  with  a 
framework  for  managing  the  use  of  PPS 
implemented  within  DoD  information 
systems.  This  allows  network  administra¬ 
tors  to  know  what  data  types  are  expected 
on  their  networks.  At  the  same  time  it 
provides  information  on  what  types  of 
traffic  to  block  to  protect  the  network. 

The  PPS  policy,  DoD  Instruction 
8551.1  [1],  states  diat  PPS  that  are  visible 
to  DoD-managed  network  components 
shall  undergo  a  vulnerability  assessment, 
be  assigned  to  an  assurance  category,  be 
appropriately  registered,  be  regulated 
based  on  its  potential  to  cause  damage  to 
DoD  operations  and  interests  if  used 
maliciously,  and  be  limited  to  only  the  PPS 
required  to  conduct  official  business.  In 
this  section,  we  will  discuss  the  processes 
of  vulnerability  assessments  and  assur¬ 
ance  category  assignments,  the  regulation 
of  use  or  elimination  of  PPS  within  the 
DoD  space,  and  die  registration  of  infor¬ 
mation  systems. 

Vulnerability  Assessments 

Vulnerability  assessments  identify  the 
security  limitations  of  PPS.  Any  known 
countermeasures  to  limit  the  exposure  of 
the  vulnerability  are  identified  in  this 
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process.  This  research  is  performed  by  the 
Technical  Advisory  Group  (TAG),  which 
consists  of  subject  matter  experts  from  all 
of  the  DoD  components,  supported  by 
technical  expertise  from  the  companies 
EDS  and  NetSec  under  the  Defense 
Information  Systems  Agency  (DISA) 
Information  Assurance  [4]  contract. 

Because  of  die  complexity  of  some 
proprietary  protocols,  it  may  be  necessary 
to  invite  service  providers  to  explain  die 
operation  of  their  protocols.  The  vulnera¬ 
bility  assessment  reports  are  available  at 
<  h  1 1  p :  /  /iase.disa.mil/  ports /index. 
html>. 

Assurance  Category  Assignments 

Assurance  category  assignments  identify 
the  relative  strength  of  PPS.  The  guidance 
discourages  the  use  of  low  assurance  PPS 
lacking  adequate  security  countermea¬ 
sures  (category  Red);  accepts  die  use  of 
medium  assurance  PPS,  provided  docu¬ 
mented  countermeasures  are  implement¬ 
ed  (category  Yellow);  and  encourages 
using  high  assurance  PPS,  which  is  con¬ 
sidered  a  best  practice  when  documented 
countermeasures  are  implemented  (cate¬ 
gory  Green) . 

Although  this  research  is  performed 
by  the  TAG,  it  is  verified  by  the 
Configuration  Control  Board  (CCB)  to 
ensure  that  proposed  countermeasures 
may  be  implemented  in  an  operational 
network  environment.  The  results  of  this 
process  are  documented  in  the  PPS 
assurance  Category  Assignments  List 
(CAL)  [5], 

Regulation 

The  regulation  of  the  PPS  in  DoD  net¬ 
work  space  is  a  Defense  Information 
System  Network  Security  Accreditation 
Working  Group  (DSAWG)  decision  based 
on  die  recommendation  of  the  CCB  and 
the  vulnerability  assessment  reports.  The 
goal  is  to  allow  only  those  PPS  that  are 
required  to  conduct  official  business  to 
cross  enclave  boundaries.  In  general,  any 
PPS  labeled  as  Red  must  not  cross  any 
enclave  boundary  into  the  DoD  network 
space. 

After  issuance  of  the  DSAWG  deci¬ 
sion,  users  of  information  systems  imple¬ 
mented  with  Red  PPS  will  be  notified  and 
the  DoD  PPS  program  manager  (PM)  will 
assist  diem  with  compliance.  Within  die 
two-year  compliance  timeframe,  the  infor¬ 
mation  system  may  be  redesigned  with  a 
more  secure  PPS  (Yellow  or  Green),  mod¬ 
ified  to  alter  the  communications  path,  or 
implemented  within  a  Virtual  Private 
Network  (VPN)  solution. 

Although  a  PPS  may  be  labeled  as 


Firewall  and  Router  Filtering 


Figure  5:  Firewall  and  Router  Filtering 

Red,  that  category  assignment  does  not 
necessarily  mean  that  its  use  will  be  imme¬ 
diately  eliminated  from  the  DoD  network 
space.  With  the  assistance  of  the  DoD 
PPS  program  manager,  a  DoD  compo¬ 
nent  may  request  an  appeal  for  the  imple¬ 
mentation  of  the  PPS  within  the  informa¬ 
tion  system  to  the  DoD  chief  information 
officer.  For  some  PPS  designated  as  Red, 
diere  may  be  no  more  secure  alternatives. 

The  TAG  will  review  these  PPS  peri¬ 
odically  to  determine  if  new  countermea¬ 
sures  provide  adequate  protections  or  if 
more  secure  alternative  solutions  become 
available.  The  DSAWG  decision  dates  for 
die  PPS  are  published  in  the  CAL. 

Registration 

DoD  Instruction  8551.1  requires  that  all 
existing,  new,  and  planned  DoD  informa¬ 
tion  systems  visible  to  DoD-managed  net¬ 
work  components  must  be  registered  in  a 
PPS  registry  maintained  by  DISA.  This 
process  ensures  that  all  necessary  ports 
remain  open  as  long  as  a  DoD  informa¬ 
tion  system  has  PPS  that  cross  enclave 
boundaries  into  the  DoD  network  space. 

Each  DoD  component  has  a  point  of 
contact  (POC)  who  is  authorized  to  regis¬ 
ter  information  systems.  A  list  of  die 
POCs  is  available  at  NetDefense  Joint 
Task  Force-Global  Network  Operations 
[6].  Once  registration  is  completed,  the 
process  will  automatically  notify  DoD 
network  administrators  to  open  ports  and 
protocols  as  required  on  appropriate 
DoD  routers  and  firewalls. 

If  die  registration  is  for  a  new  PPS 
configuration  in  a  newly  developed  or 
newly  acquired  DoD  information  system, 
or  for  a  modification  of  an  existing  DoD 
information  system,  the  PPS  will  be  tem¬ 
porarily  opened,  as  required,  until  the 


DSAWG  has  accepted  the  risk  of  the  PPS 
within  the  DoD  network  space.  The 
assessment  and  assignment  of  categories 
to  PPS  takes  approximately  three  months. 
Therefore,  it  is  important  to  register  infor¬ 
mation  systems  as  soon  as  possible  in  the 
development  or  acquisition  process  to 
ensure  availability  of  the  intended  PPS. 

Benefits 

Information  system  managers,  architects, 
and  developers  in  today’s  software  devel¬ 
opment  environment  are  rapidly  being  led 
to  the  realization  that  security  is  not  an 
add-on  feature  but  must  be  identified  as  a 
core  requirement  from  the  beginning. 
This  concept  is  also  referred  to  as  baked  in 
security.  The  PPSMP  registration  process 
enables  DoD  components  to  identify  and 
eliminate  poor  business  and  security  prac¬ 
tices  (e.g.,  unencrypted  remote  manage¬ 
ment  of  routers  and  firewalls  from  the 
Internet).  This  section  identifies  die  bene¬ 
fits  of  the  PPSMP  to  PMs,  system  engi¬ 
neers,  software  developers,  designated 
approving  authorities,  and  network  opera¬ 
tions  staff. 

Many  protocols  and  network-based 
services  were  designed  by  people  who 
were  not  concerned  with  malicious  behav¬ 
ior.  As  a  result,  a  computer  that  uses  these 
protocols  and  services  is  exposed  to 
attack.  However,  many  of  these  risky  pro¬ 
tocols  and  services  are  useful,  and  a  few 
are  even  necessary. 

One  way  of  dealing  with  the  risky  pro¬ 
tocol  problem  is  to  limit  the  population 
that  can  interact  using  a  particular  proto¬ 
col  or  service.  In  practice,  this  is  often 
done  by  limiting  the  use  of  a  risky  proto¬ 
col  to  the  local  workgroup,  or  local  area 
network.  A  firewall  or  filtering  router 
blocks  die  protocol  at  the  group  bound¬ 
ary,  diereby  shielding  members  of  die 
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group  from  tire  people  on  the  outside  who 
might  attack  machines  on  the  inside  that 
have  the  protocol  enabled.  Although  in 
this  case  a  firewall  is  an  enabler  of  a  capa¬ 
bility,  it  can  also  cause  interoperability 
problems  if  people  or  applications  on 
either  side  of  the  boundary  must  use  that 
risky  protocol  for  essential  communica¬ 
tion  across  the  boundary. 

The  ports  and  protocols  process  is  the 
method  the  DoD  uses  to  determine  the 
riskiness  of  particular  protocols  and  serv¬ 
ices,  and  then  balances  that  risk  against 
the  operational  utility  of  the  protocol 
with  guidance  on  when  and  how  to  use 
the  protocol  and  service. 

Program  Managers 

By  providing  PMs  with  the  list  of 
approved  PPS,  the  DoD  allows  PMs  to 
target  the  acquisition  of  systems  and  sys¬ 
tem  components  that  must  meet  interop¬ 
erability  goals  and  information  assurance 
goals.  DoD  PMs  can  request  that  the 
PPSMP  process  review  considers  using 
PPS  prior  to  making  costly  implementa¬ 
tion  decisions.  The  DoD  PPSMP  was 
developed  with  the  understanding  that 
DoD  PMs  are  continually  focused  upon 
multiple  challenges,  as  follows: 

•  Provide  and  refine  products  and  serv¬ 
ices  in  conjunction  with  the  mission 
element  needs  statement,  required 
operational  capability,  major  automat¬ 
ed  information  system  review  council, 
and  defense  information  technology 
security  certification  and  accreditation 
process  processes. 

•  Meet  the  schedule. 

•  Execute  fiscal  responsibility. 

•  Minimize  fielding  costs. 

•  Minimize  software  maintenance  costs. 

•  Reduce  time  to  accredit  and  time  to 
field. 

PMs  will  no  longer  need  to  develop 
multiple  system  baselines  to  comply  with 
different  component  firewall  policies.  The 
PPSMP  (DoD  Instruction  8551.1,  para¬ 
graph  4.8)  requires  network  security 
administrators  to  open  enclave  bound¬ 
aries  for  properly  registered  AISs  using 
recommended  PPS.  Early  adopters  of  the 
PPSMP  are  Health  Affairs  and  the  High 
Performance  Computing  Office. 

System  Engineers 

The  PPSMP  provides  the  ability  to 
choose  compatible  products  early  in  the 
system  development  cycle  and  supports  a 
standardized  architecture,  which  reduces 
configuration  management  issues  with 
network  connections.  The  PPSMP  also 
simplifies  the  accreditation  process  by 
encouraging  standard  implementation 


and  consistent  reporting  methods.  It 
reduces  rework  costs  for  system  fielding 
due  to  PPS  cross-component  conflicts. 

Software  Developers 

Software  developers  will  be  able  to  use 
the  standard  implementation  configura¬ 
tions  provided  in  the  CAL.  The  configu¬ 
rations  identified  in  the  CAL  provide  the 
target  architectures  that  have  been  vetted 
by  the  DSAWG. 

Designated  Approving  Authorities 

The  PPSMP  supports  the  designated 
approving  authorities  (DAAs)  by  identify¬ 
ing  the  technical  risk  of  using  specific 
PPS.  This  identification  enables  the 

“The  PPSMP  provides 
the  ability  to  choose 
compatible  products 
early  in  the  system 
development  cycle  and 
supports  a  standardized 
architecture,  which 
reduces  configuration 
management  issues  with 
network  connections.” 


DAAs  to  perform  informed  risk  assump¬ 
tion  evaluations  and  decisions.  The 
PPSMP  also  reduces  DAA  staff  evalua¬ 
tion  time  for  registered  AISs  and  PPS, 
which  use  standard  configurations  and  are 
fielded  in  full  compliance  with  DISA 
security  technical  implementation  guides. 

Network  Operations  Staff 

The  Network  Operations  staff  includes 
both  network  operators  and  system 
administrators.  The  PPSMP  supports  the 
Network  Operations  staff  by  providing 
standard  implementation  configurations, 
standardizing  router  configurations  with 
predefined  rule  sets  to  be  used  as  required 
to  meet  operational  requirements,  and 
reducing  hostile/unintended  traffic. 

Network  operators  are  responsible  for 
the  operations  and  maintenance  of  major 
segments  of  managed  networks.  Network 
Operations  customers  include  the  United 
States  Strategic  Command  Joint  Task 
Force-Global  Network  Operations  (JTF- 


GNO),  DISA  operations,  JTF-GNO 
Global  Network  Center,  Global  Network 
Support  Center,  Theater  Network 
Centers,  NetDefense,  and  Computer 
Emergency  Response  Teams  and 
Network  Operations  Centers  of  the  DoD 
components. 

System  administrators  are  responsible 
for  the  installation  and  maintenance  of 
information  systems,  providing  effective 
information  system  utilization,  and  ensur¬ 
ing  the  use  of  adequate  security  parame¬ 
ters  and  sound  implementation  of  estab¬ 
lished  information  assurance  policy  and 
procedures. 

Benefits  realized  by  the  Network 
Operations  staff  include  advance  notice 
of  specific  vulnerabilities,  potential 
attack  vectors  known  before  exploits 
exist  (e.g.,  Blaster,  Slammer),  and  aid  in 
the  immediate  impact  analysis  of  poten¬ 
tial  port  closures  during  attack/protec¬ 
tion  decisions.  Other  benefits  include  the 
standardization  of  router  configurations 
with  predefined  rule  sets  to  be  used  as 
required  and  the  reduction  of 
hostile/unintended  traffic. ♦ 
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